Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support non-integer exponents to handle the result of square root #3439

Merged
merged 5 commits into from
Dec 7, 2023

Conversation

HansOlsson
Copy link
Collaborator

@HansOlsson HansOlsson commented Nov 16, 2023

One problem with defining the unit for sqrt(x) as proposed in #2127 is that sqrt(1m) is 1m^(1/2).
Obviously in most cases sqrt will return a normal unit, e.g. sqrt(4m^2) is 2m, so we should not consider this as a common case.

The proposed syntax for that is unit="m^(1/2)".

There are multiple options - some of the ones I considered and rejected:

  • Don't support them at all; as we have seen that doesn't work well enough.
  • Support computing them without having a syntax for generating them; this will require work-arounds for constructing them (it's possible) but also mean that each tool will have to find some syntax in error messages, and is thus not ideal. It will also mean that we cannot write the result of unit-inference in standard Modelica.
  • Generalize the exponent to be a floating point number. The syntax will be a confusing syntax since "." is normally multiplication, so "m0.5" would be confusingly similar to "m0" times "5"; and cube-roots will be a mess, see Need built-in function for n'th root #3359 - thus restricting it to fractions seems safer. (We also use fraction in synchronous to ensure that the math is exact - no "m^(0.00001)" left-overs.)
  • Prefix to take a root: there's no good symbol in ascii - and it would be a weird mix (as squaring and square root would be on opposite ends)
  • Rational exponents with or without parenthesis: "m(1/2)" or "m1/2". I don't find them easy to understand; even if the syntax may be unambiguous.
  • Exponentiation symbol without parenthesis: "m^1/2". Mathematically that doesn't parse well, as one expects it to mean (m^1)/2.

An additional possibility would be also allow the symbol for integers. I can see this in the future, but don't think it is needed at the moment - and by being more restrictive the mapping back from internal unit (including inferred ones) to the unit-syntax is more restricted to ensure that there is no change unless needed. (A similar reason explains why the fraction must be simplified.)

@HansOlsson
Copy link
Collaborator Author

This has been sort of test-implemented in Dymola (replacing the previous "Support computing them without having a syntax for generating them"), and seems to work and be straightforward to implement.

@henrikt-ma
Copy link
Collaborator

In System Modeler we implemented the syntax "m-(1/2)". To me, this was the most direct and easily parsed generalization from today's integer exponents.

I'm not expecting that users will encounter the underlying syntax frequently, as they are generally exposed only to units nicely typeset for display purposes. For this reason, I find it more important to have consistent treatment of integers and rationals, than now introducing additional characters in the syntax for hinting that numbers in unit expressions are exponents.

@HansOlsson
Copy link
Collaborator Author

In System Modeler we implemented the syntax "m-(1/2)".

We also had some other variant originally in Dymola.

To me, this was the most direct and easily parsed generalization from today's integer exponents.

I did not consider that variant. I'm not sure how "-" is simpler for parsing than "^" (to me a previously unused character seems simpler to parse).

I assume that is also the square root of meter, so I see two problems:

  • It kind of looks like subtraction.
  • "m-(-1/2)" for its inverse would be weird.

Or did you mean "m+(1/2)" for this case? That would be more understandable (require sign and then write the fraction in parenthesis), but I don't find it nice.

@henrikt-ma
Copy link
Collaborator

henrikt-ma commented Nov 21, 2023

I did not consider that variant. I'm not sure how "-" is simpler for parsing than "^" (to me a previously unused character seems simpler to parse).

Oh, the minus sign was just there to show where the sign of a negative rational number is placed, similar to "m-1". Here are some more examples, with both integer and non-integer exponents (omitting the optional plus sign):

  • "m-2"
  • "m-(3/2)"
  • "m-1"
  • "m-(1/2)"
  • ("m0")
  • "m(1/2)"
  • "m1" (or "m")
  • "m(3/2)"
  • "m2"

@HansOlsson
Copy link
Collaborator Author

I did not consider that variant. I'm not sure how "-" is simpler for parsing than "^" (to me a previously unused character seems simpler to parse).

Oh, the minus sign was just there to show where the sign of a negative rational number is placed, similar to "m-1".

So, corresponding to the second to last in my list.

@HansOlsson HansOlsson changed the title Support non-integer exponents to handle the result of square. Support non-integer exponents to handle the result of square root Nov 22, 2023
@henrikt-ma
Copy link
Collaborator

So, corresponding to the second to last in my list.

Yes, but with clarification of where the sign goes.

@HansOlsson
Copy link
Collaborator Author

To discuss:

  • Only use when required, right?
  • Syntax: m(1/2) vs m^(1/2). Negative exponents become: m-(1/2) vs m^(-1/2)

@HansOlsson HansOlsson added this to the Phone 2023-6 milestone Nov 24, 2023
@henrikt-ma
Copy link
Collaborator

To discuss:

  • Only use when required, right?

This touches the question of non-reduced rationals. As I see it, one could separately disallow 1 in the denominator without disallowing other non-reduced rationals, as it is a much more easily checked requirement to not have 1 in the denominator than checking for common factors in general.

What about the exponent 0? What about the exponent 1? I think we should strive for consistency in allowing redundant ways to express unit factors…

  • Syntax: m(1/2) vs m^(1/2). Negative exponents become: m-(1/2) vs m^(-1/2)

I see two orthogonal questions here:

  • Syntax without sign: m(1/2) vs m^(1/2) vs m1/2 (if denominator 1 is forbidden)
  • Where to put the sign: m+(1/2) vs m(+1/2) vs m(+1/+2) (corresponding variants with ^: m^+(1/2) vs m^(+1/2) vs m^(+1/+2))

(I wish the + sign wasn't allowed, but here we are…)

In case you do a poll in the meeting today, please consider me in favor of m(1/2) and m+(1/2) due to the way this directly generalizes UNSIGNED-INTEGER to a rational number.

@HansOlsson
Copy link
Collaborator Author

Poll: (currently m2 for square meter)
m(1/2): (Selected) Henrik, Quentin, Stephan, Elena, Gerd, Hans, Markus
m^(1/2): Hans
Sign: (currently m-1 for per meter)
m-(1/2): (Selected) Henrik, Quentin, Elena, Gerd, Hans
m(-1/2): Stephan, Elena, Markus, Hans

Allow non-simplified fractions, but still prohibit m(4/2).
HansOlsson and others added 2 commits November 30, 2023 17:06
Co-authored-by: Henrik Tidefelt <henrikt@wolfram.com>
Co-authored-by: Henrik Tidefelt <henrikt@wolfram.com>
Copy link
Collaborator

@henrikt-ma henrikt-ma left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the possibly…possibly being there already before, it can also be fixed separately.

@HansOlsson HansOlsson merged commit d20ee7b into modelica:master Dec 7, 2023
1 check passed
@HansOlsson HansOlsson deleted the NonIntegerUnitExponent branch December 7, 2023 14:20
@HansOlsson HansOlsson added the M37 For pull requests merged into Modelica 3.7 label Jan 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
M37 For pull requests merged into Modelica 3.7
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants